Computer systems are widely used to store and manipulate data. Data is stored in computer system memory and manipulated by computer system programs executing on the computer system's processor. As is well known, a processor is often thought of as the “brains” of the computer system because it is the component within the computer system that executes the computer system's programs, allowing the computer system to do real work. Nevertheless, it is really the make-up of computer system's programs that determines the variety and extent of the work which can be performed. Therefore, while the capabilities of the computer system's processor are important, the ultimate throughput of a computer system is largely determined by the performance of its programs. For this reason, computer system designers are continually looking for ways to improve program performance.
One area of focus pertains to programs known in the art as event handlers. Generally speaking, an event handler is a program that receives events from the computer system's operating system (or other facility), and takes one or more actions based on the particular type of event. A very simple example is that of a printer running out of paper. Many printers will send an event to the computer system when its paper supply has been exhausted. The computer system's operating system receives this event and forwards it to an event handler. The event handler can then “handle” the event in a manner consistent with its programming. For example, the event handler may post a message to the user or system administrator and/or the event handler may cause the computer system to sound an alarm or beep. Some event handlers, particularly older designs, are monolithic in that they are specifically written to take one or more actions based upon a particular received event. The problem with this approach is the lack of flexibility. I.e., the event handler must be rewritten whenever a new event requires handling or whenever a new action is required.
In recognition of this flexibility issue, more modern event handlers have what are referred to as “registration interfaces,” which permit sub-programs to register for notification of the receipt of an event. By “sub-programs” we refer to smaller scope programs that typically have a subservient role relative to a larger program. Examples would include procedures (i.e., as used in procedural languages) and methods (i.e., as used in object-oriented languages). (In object-oriented parlance, these sub-programs are often referred to as listeners or collaborators. We make common use of the term listener in this patent.) Registering is the general act of providing sufficient information to the event handler to permit the event handler to contact the listeners at a later time. Taking the printer example, a listener might register with the event handler such that the event handler will notify it when an “out of paper” event is received. The listener would then be responsible for taking the appropriate action (e.g., a message, beep, or alarm).
The flexibility gained from this approach, however, is not without cost. FIG. 1 shows an example design of a prior art event handler. As shown, Event Handler 100 includes a Registration Interface 110. Listeners, shown on FIG. 1 as Listeners 115, then utilize Registration Interface 110 to instruct Event Handler 100 to notify them when particular events (i.e., one of events 105) are received. Thus, looking at Dynamic Event Tables 120, 130, and 135, the reader can see that different events have different listeners requiring notification. For example, receipt of a Type 1 event requires notification of listeners B, E, A, and C; whereas receipt of a Type 3 event requires notification of Listener A. Registration for a given listener includes recording its location in each event table for each event for which it requires notification. Notification is then accomplished by locating the particular listener through the location information stored in the event table and then calling the particular listener. The event tables are said to be dynamic because listeners can be added or removed via Registration Interface 110.
With this as background, the flexibility cost alluded to above is attributable to the overhead associated with first locating and then calling each listener. Referring again to receipt of a Type 1 event, Event Handler 100 must first find and call (i.e., invoke) Listener B, then Listener E, then Listener A, then Listener C. Locating listeners before invoking them is quite costly from a performance perspective. Of course, full appreciation of this problem's magnitude becomes more clear when we point out that there may be tens or hundreds of listeners registered for notification of any one event. Therefore, while modern event handlers are more flexible in that event handling capability can be added through registration, the promise of this approach is limited by the performance penalty associated with locating the multiple listeners before calling them.
Without a mechanism to provide efficient registration-based event handling, the industry will continue to be faced with the choice between older, inflexible event handler designs and newer inefficient ones.